This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The Third Generation Partnership Project (3GPP) is a collaboration of several independent standardization organizations that is focused on the development of globally applicable third generation mobile phone system specifications. The Technical Specification Group Radio Access Network (TSG RAN) is responsible for the definition of the functions, requirements and interfaces of the universal terrestrial radio access (UTRA) network in its two modes, frequency division duplex (FDD) and time division duplex (TDD).
3GPP Release 5 (Rel5) introduced a new high speed downlink shared channel (HS-DSCH). In HS-DSCH transmission utilizing a hybrid automatic-repeat-request (HARQ) system (a N-process stop-and-wait system), and due to fact that different HARQ processes may require a different number of retransmissions, the medium access layer (MAC-hs) packet data units (PDUs) are not necessarily received in order by a desiring MAC-hs receiver. For example, two packets, packet 1 and packet 2, can be sent in consecutive transmission time intervals (TTIs). In this situation, it is possible that when packet 2 is received correctly by layer 1, the packet 1 may need further transmissions before it is correctly received and delivered to the MAC-hs layer of a user equipment (UE) receiver, thus leading to packet 2 getting to the MAC-hs before packet 1 during in-sequence delivery.
In order to provide MAC-hs or MAC-ehs service data units (SDUs) in the correct order for higher layers after HARQ transmission, MAC-hs PDU reordering is performed by the receiver in the MAC-hs. This reordering is performed by using the transmission sequence number (TSN) set by the transmitter in MAC-hs. The TSN effectively provides a running sequence number for each packet so that, even though the packets are received out of order due to HARQ retransmissions, the MAC layer can easily reorder them for in-sequence delivery to the higher protocol layer.
In 3GPP Rel5, when high speed downlink packet access (HSDPA) operation was first introduced, the HSDPA was only used in a dedicated channel (CELL_DCH) state where a UE dedicated radio link and a UE dedicated resources are reserved in a base transceiver station, referred to conventionally and herein as Node B. Therefore, it was required that the transmitter set the TSN in an increasing order, starting from zero, when transmitting the MAC-hs PDUs to UE. In this situation, the receiver would always receive every consecutive TSN (0, 1, 2, 3, 4, 5, . . . ) even though the UE would not be continuously transmitted with new data in each consecutive TTI, i.e., every packet that was transmitted receives the TSN value TSNprevious—packet+1, and a missing TSN value (e.g. receive 0, 1, 2, 3, 5, 6, 7, where 4 is missing) would indicate a packet lost by L1.
In the CELL_FACH state or when HS-DSCH reception is also configured in CELL/UTRAN Registration Area Paging Channel (CELL_PCH/URA_PCH) states, however, there is no UE-specific context in Node B established by radio link (RL) setup procedure. The Node B just receives the HS-DSCH radio network identifier (H-RNTI) to be used for the transmission and the data to be transmitted from the Iub Frame Protocol connection from the RNC to the Node B, which is shared between different users. Therefore, if the conventional TSN increment method were used, then the Node B would start the TSN from zero for specific H-RNTIs (for a specific user) and increase the TSN when transmitting the next MAC-hs PDUs. However, as the UE expects the increased TSN number, the Node B would need to know the TSN that was used when the previous transmission to that particular UE took place, even if data was last transmitted to that UE quite a long time earlier.
An example of the above issue is as follows. In this example, it is helpful to consider a situation where Node B sends 1200 bits to the UE in a 4 HARQ processes (e.g., in TTIs that may be consecutive, or there may be some TTIs in which no data is sent between data-containing TTIs) with 300 bits in each TTI and with TSN values of 0, 1, 2, and 3. The UE correctly receives the PDUs and increases the next expected TSN value to 4. After the next TSN value is raised, there is a 10 second period of inactivity when Node B does not receive any data from the network that is to be delivered to the specific H-RNTI identifying this user. After this period of inactivity, another 1200 bits are then received. If Node B is able to “remember” the previous TSN setting for this particular UE, it would set the TSN to 4 for the first PDU of the 4 PDUs to be transmitted, and reordering would work as in current specification. However, if Node B cannot remember the previous TSN setting (i.e., such memory is not maintained in Node B), then Node B would need to start the TSN from zero again, essentially operating as if the next transmission is the first transmission for this UE. In this case, the UE would receive TSN 0, even though it is expecting to receive TSN 5. As a result, the UE would consider packets 4-63 to be missing (TSN is a 6-bit counter that wraps to 0 after 63), and the reordering function would buffer the freshly received packet and wait for packets 4-63 so that the data can be delivered in sequence. The UE would therefore not pass the correctly received PDUs to higher layers until the T1 timer is expired (the T1 timer defines the time that the reordering function waits for missing packets from the sequence before declaring them lost). In light of the above, if the TSN is not correctly set, the MAC-hs reordering function in the UE will consider a TSN to be received out of order and wait until a predefined time (T1), thereby introducing an unnecessary delay for transmission of the first packets received after a period of inactivity.
In an alternative to the above, it is also possible for Node B to keep record of transmissions and use TSN numbers for specific H-RNTI instances. However, there is currently no system for Node B to determine how long such records should be kept, as the Node B would, for example, know if the UE identified by a specific H-RNTI moved to a cell controlled by some other Node B and that H-RNTI was to be allocated to some other UE by the RNC. For example, an H-RNTI instance can be allocated to another UE during the time frame at issue, and then the TSN would once again be incorrectly set.
In accordance with the above, the above issue has been conventionally addressed by either resetting the MAC-hs, and thus resetting the TSN signaling to zero via dedicated RRC signaling, or always delaying the delivery of packets from the reordering function to the higher protocol layer by the length of the T1 timer.